About Microsoft Entra Workload ID
When you configure your cluster to use manual mode with Microsoft Entra Workload ID, the individual Red Hat OpenShift Container Platform cluster components use the Workload ID provider to assign to components short-term security credentials.
Microsoft Entra Workload ID authentication process
You should familiarize yourself with the Microsoft Entra Workload ID authentication flow.
The following diagram details the authentication flow between Microsoft Azure and the Red Hat OpenShift Container Platform cluster when using Workload ID.
Azure component secret formats
To change the content of the Azure credentials that are provided to individual Red Hat OpenShift Container Platform components, you can use manual mode with with Microsoft Entra Workload ID.
Compare the following secret formats:
apiVersion: v1
kind: Secret
metadata:
namespace: <target_namespace>
name: <target_secret_name>
data:
azure_client_id: <client_id>
azure_client_secret: <client_secret>
azure_region: <region>
azure_resource_prefix: <resource_group_prefix>
azure_resourcegroup: <resource_group_prefix>-rg
azure_subscription_id: <subscription_id>
azure_tenant_id: <tenant_id>
type: Opaquewhere:
metadata.namespace-
Specifies the namespace for the component.
metadata.name-
Specifies the name of the component secret.
data.azure_client_id-
Specifies the client ID of the Microsoft Entra ID identity that the component uses to authenticate.
data.azure_client_secret-
Specifies the component secret that is used to authenticate with Microsoft Entra ID for the
<client_id>identity. data.azure_resource_prefix-
Specifies the resource group prefix.
data.azure_resourcegroup-
Specifies the resource group. This value is formed by the
<resource_group_prefix>and the suffix-rg.
apiVersion: v1
kind: Secret
metadata:
namespace: <target_namespace>
name: <target_secret_name>
data:
azure_client_id: <client_id>
azure_federated_token_file: <path_to_token_file>
azure_region: <region>
azure_subscription_id: <subscription_id>
azure_tenant_id: <tenant_id>
type: Opaquewhere:
metadata.namespace-
Specifies the namespace for the component.
metadata.name-
Specifies the name of the component secret.
data.azure_client_id-
Specifies the client ID of the user-assigned managed identity that the component uses to authenticate.
data.azure_federated_token_file-
Specifies the path to the mounted service account token file.
Azure component secret permissions requirements
You should familiarize yourself with the permissions required by the Red Hat OpenShift Container Platform components. These values are in the CredentialsRequest custom resource (CR) for each component.
| Component | Custom resource | Required permissions for services |
|---|---|---|
Cloud Controller Manager Operator |
|
|
Cluster CAPI Operator |
|
role: |
Machine API Operator |
|
|
Cluster Image Registry Operator |
|
Data permissions
General permissions
|
Ingress Operator |
|
|
Cluster Network Operator |
|
|
Azure File CSI Driver Operator |
|
|
Azure Disk CSI Driver Operator |
|
|
-
This component requires a role rather than a set of permissions.
OLM-managed Operator support for authentication with Microsoft Entra Workload ID
To allow certain Operators that are managed by the Operator Lifecycle Manager (OLM) on Azure clusters to authenticate with limited-privilege, short-term credentials that are managed outside the cluster, you can use manual mode with Microsoft Entra Workload ID.
To determine if an Operator supports authentication with Workload ID, see the Operator description in the software catalog.
To store and manage your secrets securely, configure the Secrets Store CSI Driver Operator to mount secrets from an external secret management system, such as Azure Key Vault, by using a provider plugin. Applications can then use the secret, but the secret does not persist on the system after pod termination.
Secret objects are stored with Base64 encoding. etcd provides encryption at rest for these secrets, but when secrets are retrieved, they are decrypted and presented to the user. If role-based access control is not configured properly on your cluster, anyone with API or etcd access can retrieve or modify a secret. Additionally, anyone who is authorized to create a pod in a namespace can use that access to read any secret in that namespace.
The Secrets Store CSI Driver Operator, secrets-store.csi.k8s.io, enables Red Hat OpenShift Container Platform to mount multiple secrets, keys, and certificates stored in enterprise-grade external secrets stores into pods as a volume. The Secrets Store CSI Driver Operator communicates with the provider using gRPC to fetch the mount contents from the specified external secrets store. After the volume is attached, the data in it is mounted into the container’s file system. Secrets store volumes are mounted in-line.
For more information about CSI inline volumes, see "CSI inline ephemeral volumes".
Familiarity with persistent storage and configuring CSI volumes is recommended when working with a CSI driver. For more information, see "Understanding persistent storage" and "Configuring CSI volumes".